Sign in to follow this  
rip-off

The great GD.net collaborative coding horror experiment? (...and the results are in!)

Recommended Posts

Chad Smith    1343

What is going to be interesting: Seeing how the advanced and the beginning type programmers work in the same exact file.  We are bound to see some crazy obscure looking C++ code followed by some C++ code that seems to be written by a beginner.

 

And knowing me I bet I will think I can follow that obscure code and end up writing something that breaks that obscure code and ends up breaking a lot of things in the project.  sad.png

Share this post


Link to post
Share on other sites
Buster2000    4310


What is going to be interesting: Seeing how the advanced and the beginning type programmers work in the same exact file. We are bound to see some crazy obscure looking C++ code followed by some C++ code that seems to be written by a beginner.

 

So just like production code in a AAA studio then :p

Share this post


Link to post
Share on other sites
rip-off    10976
Here are the slightly revised "rules" - note that they are self enforced. Please abide by the spirit of the experiment.
  • There are two experiments, one in C++ and one in HTML 5
  • Each experiment will have a thread, to be created by me, which will be populated with a minimal, terrible program
  • Each experiment will have a separate but related theme. Strive to make a playable, or even fun, game!
  • The threads will act as a kind of revision control system, each post containing code is a commit
  • You must attempt to amend the current version of the code
  • If, having posted, you find someone has committed something new, please immediately edit your post to remove the code (to avoid confusion)
  • Posts must include the full source of the program so far, but please highlight what was changed
  • The program will be in a single file only
  • Dependencies are limited to the standard library and the multimedia library only
  • Assets can be procedurally generated, or inlined into the source file, do not refer to external assets
    • For C++, the GIMP has the ability to export images into C source
    • For HTML 5, you can use a data URI
  • Remember, any assets and source code must be free of copyright restrictions
  • You can only add new code, do not remove existing code
    You may alter existing code, but please be conservative. Here are some examples:
    • Changing numeric or string constants
    • Adding a new clause to a condition
    • Adding to an existing expression
    • Adding parameters to existing function declaration/definition/call sites
    • Adding a comment at the start of a line is allowed by this rule, but please minimise such use
    • You may also "insert" a newline after a single line comment (thus uncommenting such code)
  • The code must compile on your platform of choice, and should strive to be cross platform
    • A simple example in C++ is assuming that certain types have or share a particular size
    • Do not make OS or Browser specific calls
  • Your code must not crash (to the best of your ability)
  • Bad commits are ignorable under the "amend the current version" rule. Please clearly state if this step is taken
  • For the sake of the experiment, please:
    • Try keep each commit relatively small and cohesive - for example add or change a single feature at most
    • Avoid committing twice in a row (if the thread is quiet, feel free to ignore this one)
  • Have fun everyone!
Edited by rip-off

Share this post


Link to post
Share on other sites
Cornstalks    7030

I've made a repo (totally unofficial) which I'll use to track the history of the two programs. I plan on making two branches, "c++" and "web", where the two programs will be separately tracked. If you have any feedback/questions about the repo, please just let me know (either via thread or PM).

 

I'm excited for this!

Share this post


Link to post
Share on other sites
Cornstalks    7030

Sorry for the double post, but I want to point out that in the commit history, I plan on deleting all trailing whitespace and converting tabs to spaces. If you have objections, speak now.

 

As for rules... rip-off, do you care if indentation changes between commits? My editor automatically changes tabs to spaces for me and deletes trailing white space. If you don't want indentation to change at all (and to create a mix of tabs and spaces), I can change my editor, but I want to know before I make any changes to the code.

Share this post


Link to post
Share on other sites
rip-off    10976


I've made a repo (totally unofficial) which I'll use to track the history of the two programs.

Great stuff!

 


As for rules... rip-off, do you care if indentation changes between commits?

Good point, I didn't think of that. No, I don't mind particularly. It will be interesting to see if the community follows the established coding standard or does it become a riot of styles.

Share this post


Link to post
Share on other sites
slicer4ever    6760

why is 

while(running)  
replaced with  
void loop() {
...
if(running) { loop() } 

}
shouldn't that cause a Stack Overflow?


tail-recursion, since the function doesn't return meaningful data, the compiler effectively turns it back into a loop.

edit: note that with no optimizations on, the compiler won't do this, and you'll get a overflow crash. Edited by slicer4ever

Share this post


Link to post
Share on other sites
swiftcoder    18428


edit: note that with no optimizations on, the compiler won't do this, and you'll get a overflow crash.

Note that I spent a good 20 minutes with optimisations disabled trying to get a stack overflow out of this, and ultimately failed.

 

That said, the stack frame just isn't very large at this point. It might take quite a while to actually reach the 8 MB stack limit.

Share this post


Link to post
Share on other sites
slicer4ever    6760

edit: note that with no optimizations on, the compiler won't do this, and you'll get a overflow crash.

Note that I spent a good 20 minutes with optimisations disabled trying to get a stack overflow out of this, and ultimately failed.


really? what compiler are you using? i got it very quickly when i ran your commit. I think the current crash is related to the spawnTicks variable, and the tail recursion, trying to figure it out now. Edited by slicer4ever

Share this post


Link to post
Share on other sites
swiftcoder    18428

really? what compiler are you using? i got it very quickly when i ran your commit.

Clang.

 

If you dial GCC or Clang up to -O3, you should be pretty much guaranteed to get tail call optimisation.

 

I think /O2 in Visual Studio will enable the same, but I don't have a Windows box around to test on.

Edited by swiftcoder

Share this post


Link to post
Share on other sites
rip-off    10976
With many thanks to all the contributors, the experiment is ending. This merely means that I am going to unpin the topics, the threads will not be locked or anything. Please feel free to continue adding to the experiments if you wish.
 
I'm very happy with how the C++ experiment turned out, the basis of a full game was created. The HTML 5 one almost got there in the end, but is definitely that bit more immature, which I would put down to weaknesses both in the concept and the initial art I created for it. Nonetheless, it was still interesting to see the changes that people made in both experiments.
 
I'm also quite pleased with the level of horror in the resulting C++ program. Really has some nice WTF moments, imagine yourself coming across this as a completed codebase rather than being aware of the process that created it. The HTML 5 experiment, while showing some promise, didn't really get to the level of complexity or iteration to develop more than relatively minor warts.
 
[hr]
 
The "results" (i.e, my personal opinions) of this experiment are:

 


Art availability is vital

 
It would appear that most non-artists are reluctant to contribute programmer's art. Artists who aren't programmers are discouraged from contributing, probably due to the developer-oriented rules. Gameplay programmers can only work with what is already available, and if that is very limiting it stunts the entire process.

Content is more than art

 
Art is obvious, but audio is also key to game juiciness. It would have been nice to highlight this experiment in the sub-fora, maximising the chances of participation. I don't know if the forum software has a "nice" way to handle this, as obviously I'd like to avoid cross posting.

Initial content is crucial

 
I didn't plan this aspect thoroughly, I just threw a minimal program out, it was only in the last hour did I decide to even post something more than have a black screen. I really failed to take into account the needs of the games that might evolve, I cranked out two basic sprites just before opening the experiment.
 
The initial ghost sprite turned out to be quite amenable to wrapping gameplay around. I think in many ways this single thing is the reason why the C++ was as popular as it turned out to be.
 
Unfortunately, for the HTML Frankenstein's head was, I feel, a barrier to gameplay. Not only did it lack animation, it wasn't even a complete sprite. I tried adding more sprites into the mix after the fact, but by then the program had already started to evolve and due to the rules it wasn't really possible to undo this direction. Had the initial art been better, maybe a game would have emerged sooner - which may have lent some coherency to the earlier changes.

No chefs can also cause broth related problems

 
Another issue is how to co-ordinate content creation with the gameplay programmers. For example, we had a fantastic sprite contributed to the C++ experiment by riuthamus, but unfortunately this was never really built upon - most likely because it lacked animation. Another member added a rather jarring random background gradient early in the HTML 5 experiment, which was difficult to integrate into a game. There was no barrier to gameplay programmers and content creators discussing this in the threads (except perhaps the apparent lack of the latter type of participant). A note in the rule thread encouraging such collaboration might have helped. 
 

Don't settle on the first theme that comes to mind

 
Like the art, I didn't really think the theme all the way through. This is my first try at running a public game making event like this. Initially I wasn't going to have a theme, but when I learned that the "Power Up Table Tennis" competition was ending around Halloween night, I thought it would be easy to throw a Halloween based theme around the experiments - how naïve!
 
This might sound a bit obvious, but if you are organising an event like this, I highly recommend doing some thought experiments on what kind of games you would come up with given the themes that you are planning. If you can quickly think of a handful of games that sound like they might be fun and relatively small in scope, then that concept might be a good one, while if you struggle to envision games then so will your participants.

Cross platform is a hard problem

 
While I did mention this as a hazard to watch out for in the rules, I guess the fundamental issue is that this is a hard problem when not all contributors have access to the same platforms. I'd be open to suggestions that might alleviate this problem.

Not everyone who expressed an interest will contribute

 
This didn't exactly come as a surprise to me. However, I was initially going to run a single experiment, but based on the feedback I chose to start a second in HTML 5 too. rather than not run the C++ one. I wasn't, and still am not, sure this was the right decision. I think there was just enough participation in both threads to justify this decision, but even in the first few days that wasn't necessarily very clear.
 
I had hoped that given the low commitment (not a full game, any change would do), that a few more people would manage to make a contribution, but alas not. Anyone want to chime in with  any structural reasons why they ended up choosing not to contribute despite earlier enthusiasm. By [i]structural[/i], I mean reasons related to the running of the experiments and not on personal reasons such as free time, etc.
 

I probably should have announced a fixed duration

 
I was thinking of running it for just a weekend, and then for a week. Once it was in motion, because I hadn't really committed to a set end date I kept it running while there were still contributions being made. Partially this was because I ended up being busy on most of the weekends where it would have been natural to draw it to a close.
 
[hr]
 
I'd be interested in hearing opinions from observers or contributors on anything particular that was either enjoyable or not. Any thoughts?
Edited by rip-off

Share this post


Link to post
Share on other sites
slicer4ever    6760
i really liked this idea, it was fun. I just wish their were more contributors, or consistent contributors. I hope i didn't alienate anyone away with some of the contributions i made, i know a couple of them were rather large compared to other people. also for the c++ compo, major props has to be given to gzaloprgm and bacterius for the physics code. it was very fun discussing with bact in the forum chat, two different approaches he and i took to come up with fixing the singularity of the gravity well he added with his first commit had(it was his we went with, but both approaches gave very interesting and awesome movement mechanics for the ghosts).

but all in all, everyone made great contributions, and with only a few minor bugs as well =-).
(i'm pretty sad that bact got that rendering issue, i'm almost convinced it's the way sfml handles fonts, but he'd have to be the one to debug it.)

It'd be nice to hear reasons why some people might have shyed away from making a contribution that seemed rather enthusiastic with this original thread.

Share this post


Link to post
Share on other sites
swiftcoder    18428


Anyone want to chime in with  any structural reasons why they ended up choosing not to contribute despite earlier enthusiasm. By structural, I mean reasons related to the running of the experiments and not on personal reasons such as free time, etc.

I think the specific framing of the competition discouraged me from contributing more than trivially:

 

- Managing the source code via the forum was a tremendous hassle compared to using git, and it just wasn't worth going through. In particular, making a change, refreshing the page, and discovering that you needed to manually rebase your changes on someone else's was just untenable. Anyone on this forum should be able to use/learn git, and I don't think we should be ignoring the right tools for this sort of thing.

 

- The competition was pitched more as a coding horror than as an effort to develop a complete game, so I was caught off guard when people started taking it seriously.

 

- The rules favoured very small incremental changes, and I didn't see a path to adding features that way. Major changes seemed against the spirit of the competition, so I didn't add any features in the end.

Share this post


Link to post
Share on other sites
Ganoosh    774

It was fun! Would definitely try to contribute more if there's another one.  As for why I didn't contribute more (I wanted to do more than I did), the biggest issue was I personally didn't have enough time (I would assume similar for others as well). I know that's not what you wanted to hear, but it also ties in with any "structural" problems I noticed. If I had infinite time and less other priorites, I would've done way more regardless.

 

I mostly agree with swiftcoder, see my comments below.

 

I hope i didn't alienate anyone away with some of the contributions i made, i know a couple of them were rather large compared to other people.

Not to call you out slicer, but your large commits were part of the reason I didn't do more later on. They were great! =D Just too much at once. There were some others as well, but towards the end you were doing most of the commits (which were rather large lol) with my adding some effects. I didn't have much time to put into it as I would've liked, and anytime I checked back it was a huge change. More to absorb and think about, rather than just playing for a few minutes and making some small updates.  Although I guess this would be just as much of a problem for someone only checking every few days or once a week. unsure.png

 

 

 


Anyone want to chime in with  any structural reasons why they ended up choosing not to contribute despite earlier enthusiasm. By structural, I mean reasons related to the running of the experiments and not on personal reasons such as free time, etc.

I think the specific framing of the competition discouraged me from contributing more than trivially:

 

- Managing the source code via the forum was a tremendous hassle compared to using git, and it just wasn't worth going through. In particular, making a change, refreshing the page, and discovering that you needed to manually rebase your changes on someone else's was just untenable. Anyone on this forum should be able to use/learn git, and I don't think we should be ignoring the right tools for this sort of thing.

 

- The competition was pitched more as a coding horror than as an effort to develop a complete game, so I was caught off guard when people started taking it seriously.

 

- The rules favoured very small incremental changes, and I didn't see a path to adding features that way. Major changes seemed against the spirit of the competition, so I didn't add any features in the end.

 

I didn't really have a problem with the forum commits, and someone did start a repo (though it wasn't really maintained). I wouldn't have a problem with git being a must for the next one though.

 

As for the horror aspect, I think the horror was more supposed to be the mashup of code snippets, not the game itself. Either way it was stil fun! 

 

Going back to the commit size, I think smaller commits should be more enforced. Anytime I'd check with an idea of something to add, when I had time to later to do it someone had added it already. I was going to do a surprise physics update near the beginning but I was beat to it. Then I wasn't sure what to do next, and my ideas would get behind. I was going to add text support before that update was rolled out lol. I thought to add these things because they were small and quick, but essential systems. All the while, each commit adding these features would change gameplay as well. I ended up mainly just adding effects systems that weren't there yet. I think it should be limited to adding a single feature or small amounts of changes. I'm not picking any names this time tongue.png but a lot of updates would add some subsystem as well as update gameplay, change some previous functionality etc. Just made it harder to keep up with in the time I had. I feel if commits are more limited, even with more activity, less will change with time. This would obviously take longer to complete something playable and fun, but I think it would give more chance for people to contribute what they can. Plus more contributers with small changes + different coding styles = lots more horror! =]

 

Also, with larger updates, a lot of gameplay is more the result of one person's idea. This only allows further building on it, and that can only be done so much for any game, really. You also have to "adjust" to that thinking to come with further good ideas as well. Not that this is necessarily bad, but if more people contributed smaller gameplay elements, I think it would be able to evolve more with less effort from each contributor.

 

It was fun though, and everyone did an awesome job! biggrin.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this