Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


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


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
65 replies to this topic

#61 swiftcoder   Senior Moderators   -  Reputation: 10361

Posted 02 November 2013 - 10:02 AM


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, 02 November 2013 - 10:06 AM.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


Sponsor:

#62 rip-off   Moderators   -  Reputation: 8672

Posted 02 November 2013 - 11:35 AM

In default Debug settings I was getting the stack overflow on Visual Studio.

#63 rip-off   Moderators   -  Reputation: 8672

Posted 01 December 2013 - 02:53 PM

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.
 
 
 
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 structural, 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.
 
 
 
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, 01 December 2013 - 02:54 PM.


#64 slicer4ever   Crossbones+   -  Reputation: 3979

Posted 01 December 2013 - 04:03 PM

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.
Check out https://www.facebook.com/LiquidGames for some great games made by me on the Playstation Mobile market.

#65 swiftcoder   Senior Moderators   -  Reputation: 10361

Posted 01 December 2013 - 09:37 PM


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.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#66 FuzzyRhombus   Members   -  Reputation: 773

Posted 02 December 2013 - 07:14 PM

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






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS