Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualAllEightUp

Posted 31 March 2013 - 09:30 AM

Also does anyone advice towards what genre to stay away from, we have a concept (which we all REALLY like) for a RTS game but the IA of an RTS kind of scares me (although we do, do an advance AI module next year), but I'm sure we/i can work something out.

 

 

Also does anyone have any advice about the order of development of the game engine? I would assume, from the books i have read, it would go something like:

  1. Some Graphical output
  2. Input
  3. Level editor (i know there are some free ones online, which we might use)
  4. [Some awesome mechanic]
  5. More advance graphical (lighting, Fog of War etc)
  6. Polish input / mechanics

The real question is "why from scratch"?  There are a number of things in this list which can be described in two pieces: the low level and the high level.  Take input for example, there is the low level bit of just detecting things like the mouse, keyboard, joysticks/gamepads and figuring out what buttons are available and all that.  (I.e. does the mouse have 3 or more buttons, a scroll wheel, how many axis' does the joystick present, number of buttons, pov hat etc etc etc and a few more etc.)  Then there is the high level of using the input, hooking it to your game, mapping controls to various bits of the game from the divergent set of input devices etc.  Having done both levels a couple times, I can pretty much say that the low level nitpicks are something you should seriously consider avoiding by using an existing library such as OIS.  This leaves you with plenty of discussion space in terms of how you map controls into the game and complexities of making input feel good for the user but free's you from the low level boring details which I seriously doubt you will be wanting to talk about.  (Not to mention that OIS allows cross platform support which is an absolute nightmare for input devices sometimes.)

 

So, given this explanation of my thinking, let me break down your list a bit more:

 

  • Environment:  VC, CodeBlocks, Eclipse, Cross platform, other?
  • Intended work flow: agile, tdd, freeform?  This can modify your environment such as requiring work involving setting up for unit testing and such.
  • Math library.  An overlooked item, math is the basis to any game and a good math library is critical from day one.  Even with a 2D game you probably want a base minimum of Vector, Matrix and simple line, ray, circle/sphere, plane/halfspace concepts with some intercepts and containment functionality at least planned for.  NOTE: I'm an absolute nitpicker about math libraries, I've worked with some which just added things as required and it almost always turns into a mess of massively monolithic hair brained inconsistent design with a mix of left and right handed concepts which end up causing all sorts of problems later on.  I'm actually planning out a math library for the fourth part of the series about build environment and tdd.  (Here)
  • Low level input.  I.e. I suggest OIS or another open source library to avoid the details.
  • Low leve 'graphics' though I consider this just getting a window up on screen and the 'devices' attached properly.  As with input, I would suggest a library such as Glfw or SlimDx and avoid the nit picks.
  • Integration with the sound library, you mentioned FMod.
  • At this point write something really simple to get a first pass test/integration.  I.e. an asteroids style ship with borders such that you thrust around, it plays sound, hit a border it bounces and plays sound.  You end up using all the above pieces for this and know if you have it setup.

I could keep breaking this up but getting this far is a very solid milestone.  You are likely to find all sorts of difficulties getting to this point.  Not to mention that a good solid and consistent math library should take at least a day or two, if not more if you consider potentially wanting SIMD support for extra speed.  (Simd is not something you can easily bolt on later, make the decision up front.)

 

P.S. I reread this, guess I'm just a little bit negative about prior math libraries I've worked with, ya think? smile.png  And of course the editor decided to add in a bunch of stuff..  Will try to fix it..


#3AllEightUp

Posted 31 March 2013 - 09:28 AM

Also does anyone advice towards what genre to stay away from, we have a concept (which we all REALLY like) for a RTS game but the IA of an RTS kind of scares me (although we do, do an advance AI module next year), but I'm sure we/i can work something out.

 

 

Also does anyone have any advice about the order of development of the game engine? I would assume, from the books i have read, it would go something like:

  1. Some Graphical output

  2.  

  3. Input

  4.  

  5. Level editor (i know there are some free ones online, which we might use)

  6.  

  7. [Some awesome mechanic]

  8.  

  9. More advance graphical (lighting, Fog of War etc)

  10.  

  11. Polish input / mechanics

The real question is "why from scratch"?  There are a number of things in this list which can be described in two pieces: the low level and the high level.  Take input for example, there is the low level bit of just detecting things like the mouse, keyboard, joysticks/gamepads and figuring out what buttons are available and all that.  (I.e. does the mouse have 3 or more buttons, a scroll wheel, how many axis' does the joystick present, number of buttons, pov hat etc etc etc and a few more etc.)  Then there is the high level of using the input, hooking it to your game, mapping controls to various bits of the game from the divergent set of input devices etc.  Having done both levels a couple times, I can pretty much say that the low level nitpicks are something you should seriously consider avoiding by using an existing library such as OIS.  This leaves you with plenty of discussion space in terms of how you map controls into the game and complexities of making input feel good for the user but free's you from the low level boring details which I seriously doubt you will be wanting to talk about.  (Not to mention that OIS allows cross platform support which is an absolute nightmare for input devices sometimes.)

 

So, given this explanation of my thinking, let me break down your list a bit more:

 

  • Environment:  VC, CodeBlocks, Eclipse, Cross platform, other?

  • Intended work flow: agile, tdd, freeform?  This can modify your environment such as requiring work involving setting up for unit testing and such.

  • Math library.  An overlooked item, math is the basis to any game and a good math library is critical from day one.  Even with a 2D game you probably want a base minimum of Vector, Matrix and simple line, ray, circle/sphere, plane/halfspace concepts with some intercepts and containment functionality at least planned for.  NOTE: I'm an absolute nitpicker about math libraries, I've worked with some which just added things as required and it almost always turns into a mess of massively monolithic hair brained inconsistent design with a mix of left and right handed concepts which end up causing all sorts of problems later on.  I'm actually planning out a math library for the fourth part of the series about build environment and tdd.  (Here)

  • Low level input.  I.e. I suggest OIS or another open source library to avoid the details.

  • Low leve 'graphics' though I consider this just getting a window up on screen and the 'devices' attached properly.  As with input, I would suggest a library such as Glfw or SlimDx and avoid the nit picks.

  • Integration with the sound library, you mentioned FMod.

  • At this point write something really simple to get a first pass test/integration.  I.e. an asteroids style ship with borders such that you thrust around, it plays sound, hit a border it bounces and plays sound.  You end up using all the above pieces for this and know if you have it setup.

I could keep breaking this up but getting this far is a very solid milestone.  You are likely to find all sorts of difficulties getting to this point.  Not to mention that a good solid and consistent math library should take at least a day or two, if not more if you consider potentially wanting SIMD support for extra speed.  (Simd is not something you can easily bolt on later, make the decision up front.)

 

P.S. I reread this, guess I'm just a little bit negative about prior math libraries I've worked with, ya think? smile.png


#2AllEightUp

Posted 31 March 2013 - 09:27 AM

Also does anyone advice towards what genre to stay away from, we have a concept (which we all REALLY like) for a RTS game but the IA of an RTS kind of scares me (although we do, do an advance AI module next year), but I'm sure we/i can work something out.

 

 

Also does anyone have any advice about the order of development of the game engine? I would assume, from the books i have read, it would go something like:

  1. Some Graphical output
  2.  
  3. Input
  4.  
  5. Level editor (i know there are some free ones online, which we might use)
  6.  
  7. [Some awesome mechanic]
  8.  
  9. More advance graphical (lighting, Fog of War etc)
  10.  
  11. Polish input / mechanics

The real question is "why from scratch"?  There are a number of things in this list which can be described in two pieces: the low level and the high level.  Take input for example, there is the low level bit of just detecting things like the mouse, keyboard, joysticks/gamepads and figuring out what buttons are available and all that.  (I.e. does the mouse have 3 or more buttons, a scroll wheel, how many axis' does the joystick present, number of buttons, pov hat etc etc etc and a few more etc.)  Then there is the high level of using the input, hooking it to your game, mapping controls to various bits of the game from the divergent set of input devices etc.  Having done both levels a couple times, I can pretty much say that the low level nitpicks are something you should seriously consider avoiding by using an existing library such as OIS.  This leaves you with plenty of discussion space in terms of how you map controls into the game and complexities of making input feel good for the user but free's you from the low level boring details which I seriously doubt you will be wanting to talk about.  (Not to mention that OIS allows cross platform support which is an absolute nightmare for input devices sometimes.)

 

So, given this explanation of my thinking, let me break down your list a bit more:

 

  • Environment:  VC, CodeBlocks, Eclipse, Cross platform, other?
  • Intended work flow: agile, tdd, freeform?  This can modify your environment such as requiring work involving setting up for unit testing and such.
  • Math library.  An overlooked item, math is the basis to any game and a good math library is critical from day one.  Even with a 2D game you probably want a base minimum of Vector, Matrix and simple line, ray, circle/sphere, plane/halfspace concepts with some intercepts and containment functionality at least planned for.  NOTE: I'm an absolute nitpicker about math libraries, I've worked with some which just added things as required and it almost always turns into a mess of massively monolithic hair brained inconsistent design with a mix of left and right handed concepts which end up causing all sorts of problems later on.  I'm actually planning out a math library for the fourth part of the series about build environment and tdd.  (Here)
  • Low level input.  I.e. I suggest OIS or another open source library to avoid the details.
  • Low leve 'graphics' though I consider this just getting a window up on screen and the 'devices' attached properly.  As with input, I would suggest a library such as Glfw or SlimDx and avoid the nit picks.
  • Integration with the sound library, you mentioned FMod.
  • At this point write something really simple to get a first pass test/integration.  I.e. an asteroids style ship with borders such that you thrust around, it plays sound, hit a border it bounces and plays sound.  You end up using all the above pieces for this and know if you have it setup.

I could keep breaking this up but getting this far is a very solid milestone.  You are likely to find all sorts of difficulties getting to this point.  Not to mention that a good solid and consistent math library should take at least a day or two, if not more if you consider potentially wanting SIMD support for extra speed.  (Simd is not something you can easily bolt on later, make the decision up front.)

 

P.S. reread this, guess I'm just a little bit negative about prior math libraries I've worked with, ya think? :)


#1AllEightUp

Posted 31 March 2013 - 09:06 AM

Also does anyone advice towards what genre to stay away from, we have a concept (which we all REALLY like) for a RTS game but the IA of an RTS kind of scares me (although we do, do an advance AI module next year), but I'm sure we/i can work something out.

 

 

Also does anyone have any advice about the order of development of the game engine? I would assume, from the books i have read, it would go something like:

  1. Some Graphical output

  2. Input

  3. Level editor (i know there are some free ones online, which we might use)

  4. [Some awesome mechanic]

  5. More advance graphical (lighting, Fog of War etc)

  6. Polish input / mechanics

The real question is "why from scratch"?  There are a number of things in this list which can be described in two pieces: the low level and the high level.  Take input for example, there is the low level bit of just detecting things like the mouse, keyboard, joysticks/gamepads and figuring out what buttons are available and all that.  (I.e. does the mouse have 3 or more buttons, a scroll wheel, how many axis' does the joystick present, number of buttons, pov hat etc etc etc and a few more etc.  Then there is the high level of using the input, hooking it to your game, mapping controls to various bits of the game from the divergent set of input devices etc.  Having done both levels a couple times, I can pretty much say that the low level nitpicks are something you should seriously consider avoiding by using an existing library such as OIS.  This leaves you with plenty of discussion space in terms of how you map controls into the game and complexities of making input feel good for the user but free's you from the low level boring details which I seriously doubt you will be wanting to talk about.  (Not to mention that OIS allows cross platform support which is an absolute nightmare for input devices sometimes.)

 

So, given this explanation of my thinking, let me break down your list a bit more:

 

  • Environment:  VC, CodeBlocks, Eclipse, Cross platform, other?
  • Intended work flow: agile, tdd, freeform?  This can modify your environment such as requiring work involving setting up for unit testing and such.
  • Math library.  An overlooked item, math is the basis to any game and a good math library is critical from day one.  Even with a 2D game you probably want a base minimum of Vector, Matrix and simple line, ray, circle/sphere, plane/halfspace concepts with some intercepts and containment functionality at least planned for.  NOTE: I'm an absolute nitpicker about math libraries, I've worked with some which just added things as required and it almost always turns into a mess of massively monolithic hair brained inconsistent design with a mix of left and right handed concepts which end up causing all sorts of problems later on.  I'm actually planning out a math library for the fourth part of the series about build environment and tdd.  (Here)
  • Low level input.  I.e. I suggest OIS or another open source library to avoid the details.
  • Low leve 'graphics' though I consider this just getting a window up on screen and the 'devices' attached properly.  As with input, I would suggest a library such as Glfw or SlimDx and avoid the nit picks.
  • Integration with the sound library, you mentioned FMod.
  • At this point write something really simple to get a first pass test/integration.  I.e. an asteroids style ship with borders such that you thrust around, it plays sound, hit a border it bounces and plays sound.  You end up using all the above pieces for this and know if you have it setup.

I could keep breaking this up but getting this far is a very solid milestone.  You are likely to find all sorts of difficulties getting to this point.  Not to mention that a good solid and consistent math library should take at least a day or two, if not more if you consider potentially wanting SIMD support for extra speed.  (Simd is not something you can easily bolt on later, make the decision up front.)


PARTNERS