Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualrpiller

Posted 30 May 2013 - 03:28 PM

@ApochPiQ I'm not disagreeing with anything you are saying. I totally understand it, but this is about trying something different. smile.png

 

I like to think of this design as event component oriented. All interactions are event driven only. There is a Game object but it's main purpose is to wire the events to functions and call all the GameObject Update methods. There is no actual "logic" in it as in there is no looping or if statements or any of that. It's just the central place to wire the objects. In my ideal indie team there would be 1 master who wires the components together. The other programmers just worry about the components themselves. Everything is event driven. All interactions are event driven. Again, it's about trying something different.

 

I wouldn't consider that a Mud class then so that anti-pattern is off the table. "Excess" indirection and layers is pretty subjective so who's to say in that. But again I'm not worrying about the glue part of it and how efficient it is right now. I'm more concerned with the components.

 

I think I'm going with a basic bomberman clone. Writing up the components required now.

 

Everything we do in programming has trade-offs. If this runs a more efficient indie project where team members come and go and are spread all over the world then I will take that trade-off of having excessive indirection. I'd rather have a game that runs than no game at all ya know smile.png I think many indie games fail because their design is too coupled together making their code over a period of time unmanageable. Unless one has a better design pattern or a neurotic project manager things generally get pretty messy pretty fast. Programmers are often tripping all over each other or changes from the designer are so drastic that programmers get pissed and quit. Instead of accepting that I'm simply trying something different.

 

Some components "might" be game specific, but the idea is to try and minimize these and make more generic components. Instead of a ghost personality component I could have a hunter/runner component that can be reused in a FPS game. Some enemies will hunt the player some will run from it. Those are traits found in many games. Breaking components into their true functionality vs the game functionality. Then linking them together to get the game functionality.


#7rpiller

Posted 30 May 2013 - 03:26 PM

@ApochPiQ I'm not disagreeing with anything you are saying. I totally understand it, but this is about trying something different. smile.png

 

I like to think of this design as event component oriented. All interactions are event driven only. There is a Game object but it's main purpose is to wire the events to functions and call all the GameObject Update methods. There is no actual "logic" in it as in there is no looping or if statements or any of that. It's just the central place to wire the objects. In my ideal indie team there would be 1 master who wires the components together. The other programmers just worry about the components themselves. Everything is event driven. All interactions are event driven. Again, it's about trying something different.

 

I wouldn't consider that a Mud class then so that anti-pattern is off the table. "Excess" indirection and layers is pretty subjective so who's to say in that. But again I'm not worrying about the glue part of it and how efficient it is right now. I'm more concerned with the components.

 

I think I'm going with a basic bomberman clone. Writing up the components required now.

 

Everything we do in programming has trade-offs. If this runs a more efficient indie project where team members come and go and are spread all over the world then I will take that trade-off of having excessive indirection. I'd rather have a game that runs than no game at all ya know smile.png I think many indie games fail because their design is too coupled together making their code over a period of time unmanageable. Unless one has a better design pattern or a neurotic project manager things generally get pretty messy pretty fast. Programmers are often tripping all over each other or changes from the designer are so drastic that programmers get pissed and quit. Instead of accepting that I'm simply trying something different.

 

Some components "might" be game specific, but the idea is to try and minimize these and make more generic components. Instead of a ghost personally component I could have a hunter/runner component that can be reused in a FPS game. Some enemies will hunt the player some will run from it. Those are traits found in many games. Breaking components into their true functionality vs the game functionality. Then linking them together to get the game functionality.


#6rpiller

Posted 30 May 2013 - 03:25 PM

@ApochPiQ I'm not disagreeing with anything you are saying. I totally understand it, but this is about trying something different. smile.png

 

I like to think of this design as event component oriented. All interactions are event driven only. There is a Game object but it's main purpose is to wire the events to functions and call all the GameObject Update methods. There is no actual "logic" in it as in there is no looping or if statements or any of that. It's just the central place to wire the objects. In my ideal indie team there would be 1 master who wires the components together. The other programmers just worry about the components themselves. Everything is event driven. All interactions are event driven. Again, it's about trying something different.

 

I wouldn't consider that a Mud class then so that anti-pattern is off the table. "Excess" indirection and layers is pretty subjective so who's to say in that. But again I'm not worrying about the glue part of it and how efficient it is right now. I'm more concerned with the components.

 

I think I'm going with a basic bomberman clone. Writing up the components required now.

 

Everything we do in programming has trade-offs. If this runs a more efficient indie project where team members come and go and are spread all over the world then I will take that trade-off of having excessive indirection. I'd rather have a game that runs than no game at all ya know smile.png I think many indie games fail because their design is too coupled together making their code over a period of time unmanageable. Unless one has a better design pattern or a neurotic project manager things generally get pretty messy pretty fast. Programmers are often tripping all over each other or changes from the designer are so drastic that programmers get pissed and quit. Instead of accepting that I'm simply trying something different.

 

Some components "might" be game specific, but the idea is to try and minimize these and make more generic components. Instead of a ghost personally component I could have a hunter/runner component that can be reused in a FPS game. Some enemies will hunt the player some will run from it. Breaking components into their true functionality vs the game functionality. Then linking them together to get the game functionality.


#5rpiller

Posted 30 May 2013 - 03:23 PM

@ApochPiQ I'm not disagreeing with anything you are saying. I totally understand it, but this is about trying something different. smile.png

 

I like to think of this design as event component oriented. All interactions are event driven only. There is a Game object but it's main purpose is to wire the events to functions and call all the GameObject Update methods. There is no actual "logic" in it as in there is no looping or if statements or any of that. It's just the central place to wire the objects. In my ideal indie team there would be 1 master who wires the components together. The other programmers just worry about the components themselves. Everything is event driven. All interactions are event driven. Again, it's about trying something different.

 

I wouldn't consider that a Mud class then so that anti-pattern is off the table. "Excess" indirection and layers is pretty subjective so who's to say in that. But again I'm not worrying about the glue part of it and how efficient it is right now. I'm more concerned with the components.

 

I think I'm going with a basic bomberman clone. Writing up the components required now.

 

Everything we do in programming has trade-offs. If this runs a more efficient indie project where team members come and go and are spread all over the world then I will take that trade-off of having excessive indirection. I'd rather have a game that runs than no game at all ya know smile.png I think many indie games fail because their design is too coupled together making their code over a period of time unmanageable. Unless one has a better design pattern or a neurotic project manager things generally get pretty messy pretty fast. Programmers are often tripping all over each other or changes from the designer are so drastic that programmers get pissed and quit. Instead of accepting that I'm simply trying something different.

 

Some components will be game specific, but the idea is to try and minimize these and make more generic components. Instead of a ghost personally component I could have a hunter/runner component that can be reused in a FPS game. Some enemies will hunt the player some will run from it. Breaking components into their true functionality vs the game functionality. Then linking them together to get the game functionality.


#4rpiller

Posted 30 May 2013 - 03:22 PM

@ApochPiQ I'm not disagreeing with anything you are saying. I totally understand it, but this is about trying something different. smile.png

 

I like to think of this design as event component oriented. All interactions are event driven only. There is a Game object but it's main purpose is to wire the events to functions and call all the GameObject Update methods. There is no actual "logic" in it as in there is no looping or if statements or any of that. It's just the central place to wire the objects. In my ideal indie team there would be 1 master who wires the components together. The other programmers just worry about the components themselves. Everything is event driven. All interactions are event driven. Again, it's about trying something different.

 

I wouldn't consider that a Mud class then so that anti-pattern is off the table. "Excess" indirection and layers is pretty subjective so who's to say in that. But again I'm not worrying about the glue part of it and how efficient it is right now. I'm more concerned with the components.

 

I think I'm going with a basic bomberman clone. Writing up the components required now.

 

Everything we do in programming has trade-offs. If this runs a more efficient indie project where team members come and go and are spread all over the world then I will take that trade-off of having excessive indirection. I'd rather have a game that runs than no game at all ya know smile.png I think many indie games fail because their design is too coupled together making their code over a period of time unmanageable. Unless one has a better design pattern or a neurotic project manager things generally get pretty messy pretty fast. Programmers are often tripping all over each other or changes from the designer are so drastic that programmers get pissed and quit. Instead of accepting that I'm simply trying something different.


#3rpiller

Posted 30 May 2013 - 03:21 PM

@ApochPiQ I'm not disagreeing with anything you are saying. I totally understand it, but this is about trying something different. smile.png

 

I like to think of this design as event component oriented. All interactions are event driven only. There is a Game object but it's main purpose is to wire the events to functions and call all the GameObject Update methods. There is no actual "logic" in it as in there is no looping or if statements or any of that. It's just the central place to wire the objects. In my ideal indie team there would be 1 master who wires the components together. The other programmers just worry about the components themselves. Everything is event driven. All interactions are event driven. Again, it's about trying something different.

 

I wouldn't consider that a Mud class then so that anti-pattern is off the table. "Excess" indirection and layers is pretty subjective so who's to say in that. But again I'm not worrying about the glue part of it and how efficient it is right now. I'm more concerned with the components.

 

I think I'm going with a basic bomberman clone. Writing up the components required now.

 

Everything we do in programming has trade-offs. If this runs a more efficient indie project where team members come and go and are spread all over the world then I will take that trade-off of having excessive indirection. I'd rather have a game that runs than no game at all ya know smile.png I think many indie games fail because their design is too coupled together making their code over a period of time unmanageable. Unless one has a better design pattern or a neurotic project manager things generally get pretty messy pretty fast. Programmers are often tripping all over each other. Instead of accepting that I'm simply trying something different.


PARTNERS