Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualKyall

Posted 09 October 2012 - 03:35 AM

Sorry Spiro, I was trying to get the concept of building utilities for a game rather than building a game or an engine across, but I clearly didn't try hard enough. My failure. I'll remember to explain a bit more in depth in the future:

my mantra is make utilities: figure out what you need, write some specifications, extremely specific ones, as in separating different grain sizes of sand specific, for how you need it to work to best optimise your development process as well as to reduce as much risk as possible, then search for off the shelf solutions that meet your requirements, failing to find such write a solution yourself. Exactly as how spiro described getting a list of what you need and then working on those. My further recommendation is to, if you don't have existing tech to use, then aim to create the tech to support a small and simple game. And with each new game you make you build/find/implement more utilities so you can increase the scope of what you can do.

2D renderer + asset loading + architecture + audio handler = GAME[ 1 ]
2D renderer + asset loading + architecture + audio handler + better tools = GAME[ 2 ]
2D renderer + asset loading + architecture + audio handler + better tools + social connectivity = GAME[ 3 ]
3d renderer + skeletal animation + asset loading + physics + architecture + awesome tools + audio mixer + multiplayer = GAME[ n ]

And so forth.

#8Kyall

Posted 09 October 2012 - 03:35 AM

Sorry Spiro, I was trying to get the concept of building utilities for a game rather than building a game or an engine across, but I clearly didn't try hard enough. My failure. I'll remember to explain a bit more in depth in the future:

my mantra is make utilities: figure out what you need, write some specifications, extremely specific ones, as in separating different grain sizes of sand specific, for how you need it to work to best optimise your development process as well as to reduce as much risk as possible, then search for off the shelf solutions that meet your requirements, failing to find such write a solution yourself. Exactly as how spiro described getting a list of what you need and then working on those. My further recommendation is to, if you don't have existing tech to use, then aim to create the tech to support a small and simple game. And with each new game you make you build/find/implement more utilities so you can increase the scope of what you can do.

2D renderer + asset loading + architecture + audio handler = GAME[ 1 ]
2D renderer + asset loading + architecture + audio handler + better tools = GAME[ 2 ]
2D renderer + asset loading + architecture + audio handler + better tools + social connectivity = GAME[ 3 ]
3d renderer + skeletal animation + asset loading + physics + architecture + awesome tools + audio mixer + multiplayer = GAME[ n ]

And so forth.

#7Kyall

Posted 09 October 2012 - 03:35 AM

Sorry Spiro, I was trying to get the concept of building utilities for a game rather than building a game or an engine across, but I clearly didn't try hard enough. My failure. I'll remember to explain a bit more in depth in the future:

my mantra is make utilities: figure out what you need, write some specifications, extremely specific ones, as in separating different grain sizes of sand specific, for how you need it to work to best optimise your development process as well as to reduce as much risk as possible, then search for off the shelf solutions that meet your requirements, failing to find such write a solution yourself. Exactly as how spiro described getting a list of what you need and then working on those. My further recommendation is to, if you don't have existing tech to use, then aim to create the tech to support a small and simple game. And with each new game you make you build/find/implement more utilities so you can increase the scope of what you can do.

2D renderer + asset loading + architecture + audio handler = GAME[ 1 ]
2D renderer + asset loading + architecture + audio handler + better tools = GAME[ 2 ]
2D renderer + asset loading + architecture + audio handler + better tools + social connectivity = GAME[ 3 ]
3d renderer + skeletal animation + asset loading + physics + architecture + awesome tools + audio mixer + multiplayer = GAME[ n ]

And so forth.

#6Kyall

Posted 09 October 2012 - 03:35 AM

Sorry Spiro, I was trying to get the concept of building utilities for a game rather than building a game or an engine across, but I clearly didn't try hard enough. My failure. I'll remember to explain a bit more in depth in the future:

my mantra is make utilities: figure out what you need, write some specifications, extremely specific ones, as in separating different grain sizes of sand specific, for how you need it to work to best optimise your development process as well as to reduce as much risk as possible, then search for off the shelf solutions that meet your requirements, failing to find such write a solution yourself. Exactly as how spiro described getting a list of what you need and then working on those. My further recommendation is to, if you don't have existing tech to use, then aim to create the tech to support a small and simple game. And with each new game you make you build/find/implement more utilities so you can increase the scope of what you can do.

2D renderer + asset loading + architecture + audio handler = GAME[ 1 ]
2D renderer + asset loading + architecture + audio handler + better tools = GAME[ 2 ]
2D renderer + asset loading + architecture + audio handler + better tools + social connectivity = GAME[ 3 ]
3d renderer + skeletal animation + asset loading + physics + architecture + awesome tools + audio mixer + multiplayer = GAME[ n ]

And so forth.

#5Kyall

Posted 09 October 2012 - 03:35 AM

Sorry Spiro, I was trying to get the concept of building utilities for a game rather than building a game or an engine across, but I clearly didn't try hard enough. My failure. I'll remember to explain a bit more in depth in the future:

my mantra is make utilities: figure out what you need, write some specifications, extremely specific ones, as in separating different grain sizes of sand specific, for how you need it to work to best optimise your development process as well as to reduce as much risk as possible, then search for off the shelf solutions that meet your requirements, failing to find such write a solution yourself. Exactly as how spiro described getting a list of what you need and then working on those. My further recommendation is to, if you don't have existing tech to use, then aim to create the tech to support a small and simple game. And with each new game you make you build/find/implement more utilities so you can increase the scope of what you can do.

2D renderer + asset loading + architecture + audio handler = GAME[ 1 ]
2D renderer + asset loading + architecture + audio handler + better tools = GAME[ 2 ]
2D renderer + asset loading + architecture + audio handler + better tools + social connectivity = GAME[ 3 ]
3d renderer + skeletal animation + asset loading + physics + architecture + awesome tools + audio mixer + multiplayer = GAME[ n ]

And so forth.

#4Kyall

Posted 09 October 2012 - 03:35 AM

Sorry Spiro, I was trying to get the concept of building utilities for a game rather than building a game or an engine across, but I clearly didn't try hard enough. My failure. I'll remember to explain a bit more in depth in the future:

my mantra is make utilities: figure out what you need, write some specifications, extremely specific ones, as in separating different grain sizes of sand specific, for how you need it to work to best optimise your development process as well as to reduce as much risk as possible, then search for off the shelf solutions that meet your requirements, failing to find such write a solution yourself. Exactly as how spiro described getting a list of what you need and then working on those. My further recommendation is to, if you don't have existing tech to use, then aim to create the tech to support a small and simple game. And with each new game you make you build/find/implement more utilities so you can increase the scope of what you can do.

2D renderer + asset loading + architecture + audio handler = GAME[ 1 ]
2D renderer + asset loading + architecture + audio handler + better tools = GAME[ 2 ]
2D renderer + asset loading + architecture + audio handler + better tools + social connectivity = GAME[ 3 ]
3d renderer + skeletal animation + asset loading + physics + architecture + awesome tools + audio mixer + multiplayer = GAME[ n ]

And so forth.

PARTNERS