Environment Class is to contain Objects only

[ghost]

The Environment class may have the game specific objects for now, but when we will start implementing the gameArea class(sub environment), the game objects should go there.

[ghost]

With the new environment design, this is not an issue anymore, i think. I close it for now.

[ghost]

Will be resolved once scenes are implemented

[ghost]

New class: GameScene, extended from Environment.

[ghost]

Ok so I pushed the code with the GameScene class. For now I see it as a class the holds, loads, etc level data. Some functions to be later added to it would be: SaveScene <-- saves scene to a file LoadScene <-- loads scene from a file Setup <-- A variable function that is defined outside the class that sets everything up in the scene

Also, I have no idea if anything will break on your side. I has to change quite a bit of code relating to the environment.

[ghost]

I am impressed that you managed to compile the code. There is a circular depedancy:

Environment "includes" GameScene "includes" Tank "includes" Environment. I think my idea of Environment containing the scenes was not good. Maybe you have a better one?

I found this article: http://www.gamedev.net/page/resources/_/technical/game-programming/making-a-game-engine-core-design-principles-r3210 Maybe it can interest you.

[ghost]

I red the article, and it looks interesting. The scene he's talking about is bascaly the environment class of our project, and he does it with an interpendancy. I heard somewhere it's not a good idea but i guess here it's either a singleton or interdepedancy.

Singletons are evil. Don't use them.

Not a good idea apparently. The reasons why its wrong are correct.

By the way, about the game architecture, because we're still in an early stage we can test a lot of thing. I came upon this article. I've heard a lot about Data-Oriented Design. It's maybe the thing these days and this project is good opportunity to learn new things. Maybe it simplify the design, because oop means a lot of abstraction and headaches when the project gets big.

[ghost]

Yea I moved GameScene.h from Environment.h to Environment.cpp, and that somehow did not complain,

On Wed, Nov 19, 2014 at 6:58 AM, Sherushe notifications@github.com wrote:

I red the article, and it looks interesting. The scene he's talking about is bascaly the environment class of our project, and he does it with an interpendancy. I heard somewhere it's not a good idea but i guess here it's either a singleton or interdepedancy.

Singletons are evil. Don't use them.

Not a good idea apparently. The reasons why its wrong are correct.

By the way, about the game architecture, because we're still in an early stage we can test a lot of thing. I came upon this article http://gamedevelopment.tutsplus.com/articles/what-is-data-oriented-game-engine-design--cms-21052. I've heard a lot about Data-Oriented Design. It's maybe the thing these days and this project is good opportunity to learn new things. Maybe it simplify the design, because oop means a lot of abstraction and headaches when the project gets big.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/15#issuecomment-63629719.

[ghost]

I'll read the articles a bit later, but I didn't like that singleton you created from the start. I like how it solved the problem, but it looks out of place and just adds more chaos to the tangled strings.

On Wed, Nov 19, 2014 at 7:47 AM, A Braker abraker95@gmail.com wrote:

Yea I moved GameScene.h from Environment.h to Environment.cpp, and that somehow did not complain,

On Wed, Nov 19, 2014 at 6:58 AM, Sherushe notifications@github.com wrote:

I red the article, and it looks interesting. The scene he's talking about is bascaly the environment class of our project, and he does it with an interpendancy. I heard somewhere it's not a good idea but i guess here it's either a singleton or interdepedancy.

Singletons are evil. Don't use them.

Not a good idea apparently. The reasons why its wrong are correct.

By the way, about the game architecture, because we're still in an early stage we can test a lot of thing. I came upon this article http://gamedevelopment.tutsplus.com/articles/what-is-data-oriented-game-engine-design--cms-21052. I've heard a lot about Data-Oriented Design. It's maybe the thing these days and this project is good opportunity to learn new things. Maybe it simplify the design, because oop means a lot of abstraction and headaches when the project gets big.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/15#issuecomment-63629719.

[ghost]

By the way, i don't suggest to read the Data-Oriented Design, it's about optimization but the code doesn't become simpler.

I didn't like that singleton you created from the start.

I just wanted to find a solution to the design problem. The first design i had in mind was completly ignored. I still think it's the best. The interactions between objects should be outside of classes.

The environment or gameScene now should be responsible for bullet spawning, and bullet damage, etc. This way, no need to include environment in tanks and bullets. The code becomes much simpler as well, we're not building a 2d game engine.

[ghost]

The environment or gameScene now should be responsible for bullet spawning, and bullet damage, etc.

The environment is still responsible for updating objects, but on an abstract level. When I created the Environment class, I meant for it to manage any object within game that are part of the scenes, while the scenes hold data about how to construct what is in the environment.

The interactions between objects should be outside of classes.

One problem I often bump into is the following case: 1) Should the object create another object? 2) Should the object tell the Environment class to create the object? 3) Should the object be create outside of a class?

Time for one of my very crazy ideas. How about creating a static class Event? This class will be like the glue that holds pieces of the code together that would otherwise produce errors if they interacted directly. I know this is very hazy and abstract, and you seem to hate abstraction but here it goes. So the class won't include anything and would have variable types:

include

template struct AbstrVar { const type_info* type; T* var; }

template void CreateEvent(Event_Type _event, AbstrVar, T*);

AbstrVar getEvent();

On Wed, Nov 19, 2014 at 9:22 AM, Sherushe notifications@github.com wrote:

By the way, i don't suggest to read the Data-Oriented Design, it's about optimization but the code doesn't become simpler.

I didn't like that singleton you created from the start.

I just wanted to find a solution to the design problem. The first design i had in mind was completly ignored. I still think it's the best. The interactions between objects should be outside of classes.

The environment or gameScene now should be responsible for bullet spawning, and bullet damage, etc. This way, no need to include environment in tanks and bullets. The code becomes much simpler as well, we're not building a 2d game engine.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/15#issuecomment-63646357.

[ghost]

ok, let's do it like you say. We will probably learn new things. I don't hate abstractions. I don't know why you say that. Usually i abstract code, when i need to, not before.

[ghost]

By the way, what does that even mean?

One problem I often bump into is the following case: 1) Should the object create another object? 2) Should the object tell the Environment class to create the object? 3) Should the object be create outside of a class?

I can easily make our game with the deisgn I said above. I did the first draft of the Environment class with this method. But now let's do the event-driven method.