Support our Sponsors:

Go Back   Touch Arcade > Developer Discussion > Public Game Developers Forum

Reply
 
Thread Tools Display Modes
  #1  
Old 10-01-2012, 08:12 PM
DemonJim's Avatar
DemonJim DemonJim is offline
Developer
iPad (3rd Gen), iOS 7.x
 
Join Date: Nov 2010
Location: UK
Posts: 387
Default Consequences: The Worst Idea For Indie Game Development In The World?

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
Reply With Quote
  #2  
Old 10-01-2012, 08:22 PM
HTWGames HTWGames is offline
Senior Member
iPad 2
 
Join Date: Oct 2011
Location: Toronto/Vancouver
Posts: 267
Default

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!
Reply With Quote
  #3  
Old 10-01-2012, 11:37 PM
Balloon Loons Balloon Loons is offline
Senior Member
iPad (3rd Gen), iOS 5.x
 
Join Date: Jun 2012
Posts: 209
Default

This is hard to do from a programming pov because every programmer has his own style. But it is a cool idea.
Reply With Quote
  #4  
Old 10-02-2012, 03:39 AM
VRPgames VRPgames is offline
Developer
iPhone 5s, iOS 7.x
 
Join Date: Jun 2011
Location: Ireland
Posts: 60
Default

It's not going to work.
Reply With Quote
  #5  
Old 10-02-2012, 04:03 AM
MarkFromBitmenStudios's Avatar
MarkFromBitmenStudios MarkFromBitmenStudios is offline
Developer
iPad (4th Gen), iOS 6.x
 
Join Date: Apr 2011
Location: Austria, Europe
Posts: 131
Send a message via AIM to MarkFromBitmenStudios
Default

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!
Reply With Quote
  #6  
Old 10-02-2012, 05:31 AM
DemonJim's Avatar
DemonJim DemonJim is offline
Developer
iPad (3rd Gen), iOS 7.x
 
Join Date: Nov 2010
Location: UK
Posts: 387
Default

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
Reply With Quote
  #7  
Old 10-02-2012, 09:23 AM
ozzieing ozzieing is offline
Junior Member
 
Join Date: Oct 2010
Posts: 6
Default

Quote:
Originally Posted by DemonJim View Post
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
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.
Reply With Quote
  #8  
Old 10-02-2012, 10:39 AM
DemonJim's Avatar
DemonJim DemonJim is offline
Developer
iPad (3rd Gen), iOS 7.x
 
Join Date: Nov 2010
Location: UK
Posts: 387
Default

Quote:
Originally Posted by ozzieing View Post
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.
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.

Quote:
Originally Posted by ozzieing View Post
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.
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 ;-)
Reply With Quote
  #9  
Old 10-02-2012, 10:43 AM
mobile1up mobile1up is offline
Senior Member
iPad 2
 
Join Date: Nov 2008
Location: Munich, Germany
Posts: 752
Send a message via Skype™ to mobile1up
Default

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.
Reply With Quote
  #10  
Old 10-02-2012, 11:07 AM
DemonJim's Avatar
DemonJim DemonJim is offline
Developer
iPad (3rd Gen), iOS 7.x
 
Join Date: Nov 2010
Location: UK
Posts: 387
Default

Quote:
Originally Posted by mobile1up View Post
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.
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
Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Copyright 2012, TouchArcade.com, LLC.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Copyright 2008 - 2011, TouchArcade.com. Privacy Policy / DMCA Copyright Agent