Consequences: The Worst Idea For Indie Game Development In The World?

Discussion in 'Public Game Developers Forum' started by DemonJim, Oct 2, 2012.

  1. DemonJim

    DemonJim Well-Known Member

    Nov 19, 2010
    416
    5
    18
    App Developer
    UK
    OK, I had this random idea that unquestionably is the most ridiculous way to make an indie game ever. But that doesn't mean it isn't a viable experiment with any merit.

    The response to my initial babbling on Twitter was split 50:50. But if your immediate thought is 'meh it won't work' or 'you can't be serious?' I suggest you just think about this a little deeper.

    The crazy idea is this: Reasonably well experienced developers take it in TURNS to work on a game for a very limited amount of time. They each get say, two days. All using Unity to keep things nice and quick to implement. Then, they pass the whole project over to the next dev in line, who gets two days to do literally whatever they want. Lather, rinse, repeat. Until we get bored.

    But here's the key point - there is no initial design whatsoever, and each dev is free to add whatever they choose. They could add sound effects, a front-end, add a totally unrelated mini-game (ignoring the game that is already there), improve the physics or do some bug fixing or optimisation, just add some art assets, or whatever - it's literally entirely up to you.

    I guess if this were to actually go ahead we'd need some rules, something like:

    1. Devs that have had a 'go' or are yet to have a go should not try and influence what happens before/after they pass it on. Nobody gets to be producer
    2. Devs are encouraged strongly to not remove anything, unless say it's needed for optimisation (eg reducing the number of trees / enemies etc.)
    3. If you add a new scene ensure there is a way to get back
    4. Who you are and what you added will go in the changelog, so nothing offensive
    5. No branching off on your own - we keep the focus on one single main branch
    6. Nobody can ever sell the project independently. If it ever got released (!) it would just be free with the relevant people credited.
    7. No working in advance on an awesome Unity game and adding that. Only spend two days on it. Use that extra effort on your own games.
    8. DO talk about Consequences

    The idea came from an old word parlour game called Consequences.

    See I told you it was crazy but with the right people involved it could be a lot of fun to work on, and particularly a lot of fun following the changes. Please reply with your thoughts, good or bad or indifferent :)
     
  2. HTWGames

    HTWGames Well-Known Member

    Oct 10, 2011
    271
    0
    16
    Game Developer
    Toronto/Vancouver
    Logistically I would see it as a nightmare to have to go in and look at someone elses work, tracing paths back to what they had done before only to understand what is going on now.

    I look at this like I do working in the graphic design world. When you are given a piece that someone else has created and are asked to edit it, it's usually the worst thing in the world because the person before usually has their own ways and methods in doing something which may or may not be within your scope or worse, less than your scope... having to untangle threads that some boob has tied into knots because of ignorance is a really trying and frustrating thing.

    Other than that, collaboration is a pretty fun thing in these types of methods!
     
  3. Balloon Loons

    Balloon Loons Well-Known Member

    Jun 20, 2012
    209
    0
    0
    This is hard to do from a programming pov because every programmer has his own style. But it is a cool idea.
     
  4. VRPgames

    VRPgames Well-Known Member

    Jun 2, 2011
    60
    0
    0
    Ireland
    It's not going to work.
     
  5. MarkFromBitmenStudios

    MarkFromBitmenStudios Well-Known Member

    Apr 4, 2011
    133
    0
    16
    IT Architecture, Development Project Manager
    Austria, Europe
    This is the single best way to truly waste your valuable developer time and lose 2 days that you can never get back.

    After a week or two, all further devs will use all 2 days figuring out what the previous devs have done then they pass it on to the next dev who tries to figure out what has been done only to pass it on after two days to the next poor guy who will spend two days trying to figure out what the first batch of devs have already added so their stuff fits in.

    Wow, that really sounds like a great idea!
     
  6. DemonJim

    DemonJim Well-Known Member

    Nov 19, 2010
    416
    5
    18
    App Developer
    UK
    I suspect the people who don't understand how this could possibly work have never used Unity3D.

    As long as each person has half a clue what they're doing and keeps the Project Hierarchy well organised (meaning they know how to put a GameObject script in the "Scripts" folder and add a new scene to the "Scenes" folder) then understanding what's there is relatively trivial. In Unity, you literally see the game world scenes as you develop them - even moving things around while the game runs - it's all SO visual. It's not just merely a project full of huge cross-referenced source code files and folders of art assets (that need loads of tools and code to load and render them) like you're probably used to in a regular game.

    After only a few hours learning the basics of Unity recently I was able to put together a little game prototype of an R/C flying sim in about half and hour (with primitive prefabbed 3D models, full collision physics and aerodynamics and a full 3D terrain/skybox and lighting). It's that quick as it only needed about 15 lines of actual code in a couple of C# scripts as so much of it is done visually in the Unity editor.

    Anyway I'm not here to sell Unity, I only suggested that as the platform as it is so quick to do things and so easy to understand the game world and object interactions. As with everything, your mileage may vary :)
     
  7. ozzieing

    ozzieing Member

    Oct 26, 2010
    6
    0
    0
    I disagree. If you're building a simple game in Unity then what you said is true or indeed if you are adding in a basic feature then this is also true however most of the time this is not what you are working on as a programmer. A vast majority of game development is for example spent on working into the control mechanism, it'd probably take most developers a few days to truly understand how it has been built so that they can optimise it properly or to add something meaningful to it. Also different developers are going to have completely different styles and ways of doing things, what happens if someone gets half way through a feature and then has to pass it on?. Conceptually, it's quite nice. Practically, it's a logistical nightmare.
     
  8. DemonJim

    DemonJim Well-Known Member

    Nov 19, 2010
    416
    5
    18
    App Developer
    UK
    There is no way the vast majority of development time is spent on the control mechanism. If anything, core gameplay is in the minority time-wise as that's the most fundamental thing to the game which is usually pretty sorted at the prototyping stage. The vast majority of time is actually spent on all the UI, art assets, level design, and that overall final polish.

    Look at some of the impressive Unity demo projects, such as that 3rd person shooter. Anyone that know Unity knows exactly how to jump right in and make all sorts of cool changes to it.

    And who said it's only open to programmers - it's open to all developers. For example a 3D artist could add some ace 3D model prefabs for anyone to use as they wish, or replace a programmer's placeholder 3D cube (that does something gameplay-wise) with an actual model of something. Or add some textures or effects. Or a designer with basic scripting knowledge can do quite a lot too.

    You are totally right here, but that's the entire point of the experiment - to see how horrific the broth will become when you keep adding chefs ;-)
     
  9. mobile1up

    mobile1up Well-Known Member

    Nov 6, 2008
    754
    0
    16
    Technical Director
    Munich, Germany
    this would be interesting if you do a brainstorm workshop prior to starting and make some ground rules in regards to architecture, technology, libraries and coding style. this would need to be a 1 week workshop where you share ideas and then each of you take a responsibility turning the coding into 4 days coding, 1 day of review/handover to the next developer.

    would work for a local team.. :) who knows where the game would go after a while when all the different play testing happens and ideas are tweaked a little. key thing here would be foundations.
     
  10. DemonJim

    DemonJim Well-Known Member

    Nov 19, 2010
    416
    5
    18
    App Developer
    UK
    Yay! Someone who actually gets it :)

    Indeed, the list of rules on the first post were just the start of it. These would all be discussed beforehand and must be adhered to for those involved. It cannot be total anarchy so yes there have to be many rules like script components have to be called the same thing as their object, stick to certain naming conventions, folder organisation etc. etc. and agree on certain coding standards like you do in any big team (and probably decide on C# or UnityScript, but not allow mix of both).

    Great point about having a review on the handover - I hadn't even thought that far ahead, but it probably would need to be done that way. As you say people could have 4 days - that's all up for debate. It could be variable, 1 to 4 days or whatever.

    I would just want to ensure that everyone involved is experienced in their field and are fully au fait with Unity. This will not be for newbies. Otherwise you'd have a load of chancers that add nothing or worse just ruin the project (as you say this would be handled in the review but ideally they wouldn't get chance to have a go).

    Basically you have to have a published game or demo available to download. The fact is anyone who calls themselve a developer without having any demos of their work that they can show off is NOT yet a developer. Otherwise I might as well go round calling myself an F1 driver :)
     

Share This Page