Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actuall0k0

Posted 22 January 2013 - 01:38 AM

Some general things, most of them independent of coding style:

 

- Have realistic and well defined goals that are clearly communicated to members on your team

- Scope it down: your game idea is probably too damn big.  Polish takes time, things get cut, features don't exist in a bubble (unless the project fails that is).

- Iteration time is everything: Fail early and fail often, prototype mechanics, and be prepared to cut something you invested a considerable amount of time in

- Knowledge is power: profile your code, run tools that check for leaks, crank up compiler warnings, and use static analysis tools if possible

- Interfaces are king: A well designed one is the root of a clear, maintainable, and productive workflow for others.  A poor one will cut into iteration time.

- Understand that hard problems will inevitably contain immensely complex code: elegant systems rarely survive contact with real users

- Embrace time estimates and embrace making time estimates that might be completely wrong.  Do this over and over and over again.

- "Self Documenting Code" is probably only documented to you

- It's (usually) not done until it's data driven

 

 

 


#2l0k0

Posted 22 January 2013 - 01:37 AM

Some general things, most of them independent of coding style:

 

- Have realistic and well defined goals that are clearly communicated to members on your team

- Scope it down: your game idea is probably too damn big.  Polish takes time, things get cut, features don't exist in a bubble (unless the project fails that is).

- Iteration time is everything: Fail early and fail often, prototype mechanics, and be prepared to cut something you invested a considerable amount of time in

- Knowledge is power: profile your code, run tools that check for leaks, crank up compiler warnings, and use static analysis tools if possible

- Interfaces are king: A well designed one is the root of a clear, maintainable, and productive workflow for others.  A poor one will cut into iteration time.

- Understand that hard problems will inevitably contain immensely complex code: elegant systems rarely survive contact with real users

- Embrace time estimates and embrace making time estimates that might be completely wrong.  Do this over and over and over again.

- "Self Documenting Code" is probably only documented to you

- It's (usually) not done until it's data driven

 

 

 


#1l0k0

Posted 22 January 2013 - 01:36 AM

Some general things, most of them independent of coding style:

 

- Have realistic and well defined goals that are clearly communicated to members on your team

- Scope it down: your game idea is probably too damn big.  Polish takes time, things get cut, features don't exist in a bubble (unless the project fails that is).

- Iteration time is everything: Fail early and fail often, prototype mechanics, and be prepared to cut something you invested a considerable amount of time in

- Knowledge is power: profile your code, run tools that check for leaks, crank up compiler warnings, and use static analysis tools if possible

- Interfaces are king: A well designed one is the root of a clear, maintainable, and productive workflow for others.  A poor one will cut into iteration time.

- Understand that hard problems will inevitably contain immensely complex code: elegant systems rarely survive contact with real users

- Embrace time estimates and embrace making time estimates that might be completely wrong.  Do this over and over and over again.

- "Self Documenting Code" is probably only documented to you

- It's (usually) not done until it's data driven

 

 

 


PARTNERS