• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
rip-off

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

65 posts in this topic

//EDIT: See THIS POST (from page 4 of this topic when viewed with default settings) for the "[i]results[i]".

//EDIT: See THIS POST (from page 3 of this topic when viewed with default settings) for revised rules and links to the actual topics.

 

Possessed Inspired by this thread, I was curious as to what would be the outcome of a game developed collaboratively right here, with the main rule being You can only add new code, not alter or remove existing code. I'm not sure if this has been done before, while I am vaguely reminded of something gone before I cannot find any thing.

Here is how I see this "working" (or, as is perhaps more likely, going up in flames):

  • I will post a basic skeleton program. I'm thinking C++, SDL 1.2.X or SFML
  • Posts here will act as a kind of revision (un)control system, each post a "commit"
  • You must attempt to amend the current version of the code (revision number?)
  • The code change for a single "commit" should be relatively small and cohesive - add or change a single feature at most
  • Posts should highlight what was changed (if possible using a diff?)
  • Posts should include the full source of the program so far
  • The program will be in a single file only
  • Dependencies are limited to the standard library and the multimedia library only. No OS-specific calls
  • Assets may be attached to your post, they should be free of copyright restrictions
  • You can only add new code, not alter or remove existing code
  • You may, however, alter numeric or string constants in existing code
  • You may add code into existing lines:
    • Add a new clause to a condition
    • Add to an existing expression
    • Add parameters to existing function declaration/definition/call sites
    • Adding // at the start of a line is allowed by this rule (?)
    • You may also "insert" a newline after a //, thus uncommenting such code
  • The code must compile on your platform of choice, and should strive to be cross platform
  • The code must not crash, to the best of your ability
  • Bad commits are ignorable under the "amend the current version" rule

I don't know whether there should be a theme. A theme might help focus the initial work, but I think lacking a theme could have some hilarious results.

Any thoughts? If there is sufficient interest, I could post the initial version sometime soon, perhaps at the weekend (Halloween seems topical). Of course if it has all been done before I will just slink away quietly...

Edited by rip-off
Added link to "end" post
0

Share this post


Link to post
Share on other sites
The "code can't be altered" rule can be circumvented by duplicating the code and using version numbers in the function/variable names. But then again, on the other hand, if a bug is found in some existing piece of code, you want some kind of mechanism to be able to alter it...
0

Share this post


Link to post
Share on other sites

Well if the language is ruby, then you can add monkey patch code. 

0

Share this post


Link to post
Share on other sites

The "code can't be altered" rule can be circumvented by duplicating the code and using version numbers in the function/variable names.

Good point, but I think the intent here is more the spirit rather than the letter. The rules are just to give some structure.

But then again, on the other hand, if a bug is found in some existing piece of code, you want some kind of mechanism to be able to alter it...

Working around existing bugs is part of it! Edited by rip-off
0

Share this post


Link to post
Share on other sites

Does commenting out lines count as "adding code"?

I'm not sure if commenting should be allowed or disallowed, or maybe just discouraged.
0

Share this post


Link to post
Share on other sites

This is the coding equivalent of a Dwarf Fortress Succession game.

Doomed to failure.  Bound for hilarious greatness.

 

I think a theme is a good idea, though.

0

Share this post


Link to post
Share on other sites

Well if the language is ruby, then you can add monkey patch code.

I am open to suggestions on the language and libraries, but I was hoping for something reasonably popular, but not a "framework" like XNA or a full engine like Unity.

I like Ruby, but I don't feel it quite meets the popularity criteria around here.
0

Share this post


Link to post
Share on other sites

Pity. Nothing quite a hard to follow as heavily monkey patched ruby. Especially if different versions of the same function get called at different times.

0

Share this post


Link to post
Share on other sites

I'd vote for plain-old ANSI C.  It's simple enough, everybody knows it, and it's got huge potential for creating an awful mess.

Edited by mhagain
0

Share this post


Link to post
Share on other sites

I'd vote for plain-old ANSI C.  It's simple enough, everybody knows it, and it's got huge potential for creating an awful mess.

I second this.

 

I'm still not sure how the "don't remove code" thing should work, because I can basically screw all of you by doing things like:

#define ( =

I think it should be acceptable to comment out lines that you want to remove.

0

Share this post


Link to post
Share on other sites


The program will be in a single file only
..
Assets may be attached to your post, they should be free of copyright restrictions
 

 

I have never used SDL or SFML, do they not require effect files like DX / OpenGL? or would they be considered as an asset

0

Share this post


Link to post
Share on other sites
I have never used SDL or SFML, do they not require effect files like DX / OpenGL? or would they be considered as an asset

 

You can inline the effect files as std::string

0

Share this post


Link to post
Share on other sites

 

I have never used SDL or SFML, do they not require effect files like DX / OpenGL? or would they be considered as an asset

 

You can inline the effect files as std::string

 

But that would make things bloated and difficult to work with, oh wait.. ;)

 

For the sake of added confusion, I think the use of goto should be encouraged

0

Share this post


Link to post
Share on other sites

I have never used SDL or SFML, do they not require effect files like DX / OpenGL? or would they be considered as an asset

For simplicity, I was thinking the game would be 2D sprites. I was thinking the skeleton program might just be a bouncing ball or something.
 

I'd vote for plain-old ANSI C. It's simple enough, everybody knows it, and it's got huge potential for creating an awful mess.

I was considering C, but I figured some people would probably end up using C++isms anyway, by accident. Including me, in the skeleton program (whoops!). I think that more people would be comfortable with C++, rather than pure C.
 

Why don't we use HTML5 and Canvas?

Again, I'm not sure that is quite as popular as C++ here. I think the experiment will live or die on the number of participants it could garner. I'm open to correction here, but I didn't really want to start a formal poll.
 

Nothing quite a hard to follow as heavily monkey patched ruby.

I'm still not sure how the "don't remove code" thing should work, because I can basically screw all of you by doing things like...

Well, my initial idea was that the code wouldn't be intentionally poor - but instead it would turn out that way over time due to the difficulty extending the game while adhering to that rule.

Now, if people prefer to treat this as a IOCCC entry where the code is intentionally crazy, then sure. In that case, the rule makes less sense, though I think it still has some value to preserve the collaborative nature, i.e. preventing someone replacing the whole program with something completely different.
 

I think it should be acceptable to comment out lines that you want to remove.

I think that would be OK. Then again:

For the sake of added confusion, I think the use of goto should be encouraged

Why not just jump over the offending code? >=D Edited by rip-off
0

Share this post


Link to post
Share on other sites
This....is going to be a thing of beauty.

Edit: since this will be a single file, could we simply use a google doc, so multiple people can edit at the same time. Not sure how well this would work with code, and also not sure how well google identifies who has made what changes.
0

Share this post


Link to post
Share on other sites

Why not just jump over the offending code? >=D

A splendid and well thought through idea!

 

I have one more request: Can we completely exclude external assets? I think it would be much easier to work on this if it's all dumped into one gigantic source file for easy copying and pasting. It could get quite messy and painful if everyone starts throwing their zip files all around the place. Again, just inline the assets.

Edited by TheComet
0

Share this post


Link to post
Share on other sites

Can we completely exclude external assets?

 

Ideally the sprites should be hand coded as arrays. 

Or std::maps with x,y hash key and an RGB struct.

0

Share this post


Link to post
Share on other sites

Sounds good for a larf - I vote c++ (I don't actually know SFML but since the S stands for simple I can't imagine it'll be too hard to pick up)

0

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  
Followers 0