Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualrpiller

Posted 30 May 2013 - 02:50 PM

This right here is the kicker, though. Because you probably won't get it right, not on the first try. Software design is complex, and typically requires a lot of iteration. There are always things you didn't account for in the initial design, things that you at first thought would be fun or otherwise contribute to the overall experience but upon practical realization turned out to be duds, things that occur to you later that can contribute greatly, things that you just flat-out overlooked, and so on.

 

I agree. If this was a full blown game and I wanted a team to stick with me there would be iterations and evolving components. For my initial research here it'll be a very small game so the design won't be all that hard. Any iterations I need I might just do myself to prove out the idea, but hoping those will be small. I'm probably going to do a clone with this research project so "fun" factors are already created for me smile.png. This method isn't really about NOT having iterations. I just choose to limit that for the research project to prove out the method itself. If this works then I would do it again with a medium size game where I would need people to stick around and iterate the code.

 

I agree with everything you guys are saying, but I'm looking at this research as doing things a different way. Seeing if this way can work and can be efficient in building indie teams around this idea because at it's core for me that's what it's about. Trying to make a game efficiently for indie people who aren't getting paid or lose interest quickly. Can we do this differently to help that problem. I think this method can help. Just have to prove it out.

 

So many people come and go on indie projects that the code ends up so messed up and often people are scared to make changes for fear of breaking many other things. I believe "total" isolation of components can help ease that problem/fear. It's easier to tell a person to go into this component and fix it's insides (not it's interface) when it's isolated. I think this can help indie project management.


#1rpiller

Posted 30 May 2013 - 02:45 PM

This right here is the kicker, though. Because you probably won't get it right, not on the first try. Software design is complex, and typically requires a lot of iteration. There are always things you didn't account for in the initial design, things that you at first thought would be fun or otherwise contribute to the overall experience but upon practical realization turned out to be duds, things that occur to you later that can contribute greatly, things that you just flat-out overlooked, and so on.

 

I agree. If this was a full blown game and I wanted a team to stick with me there would be iterations and evolving components. For my initial research here it'll be a very small game so the design won't be all that hard. Any iterations I need I might just do myself to prove out the idea, but hoping those will be small. I'm probably going to do a clone with this research project so "fun" factors are already created for me :). This method isn't really about NOT having iterations. I just choose to limit that for the research project to prove out the method itself. If this works then I would do it again with a medium size game where I would need people to stick around and iterate the code.

 

I agree with everything you guys are saying, but I'm looking at this research as doing things a different way. Seeing if this way can work and can be efficient in building indie teams around this idea because at it's core for me that's what it's about. Trying to make a game efficiently for indie people who aren't getting paid or lose interest quickly. Can we do this differently to help that problem. I think this method can help. Just have to prove it out.


PARTNERS