SFML community forums
General => SFML projects => Topic started by: SuperV1234 on April 04, 2010, 06:22:47 pm
-
Hello, I'm new to SFML and its forum, so if this is the wrong section sorry.
I want to create a tile-based game, similar to Sokoban, for example.
I'm using C# and SFML.NET to create it. What is the best object-oriented way to create it?
---
I was thinking to have a class called Entity:
Entity(int x, int y, int z, string type)
And a class called EntityManager that contains a List<Entity>.
Then, for example, to move the player, I search in EntityManager's list an Entity with the type "player", and once I find it, I change its x to x -1.
---
Is there an easier or better way to make a Sokoban clone?
-
I think it's not a good idea to lose compile-time type-safety. Why throw a player into a container with loads of other, distinct objects? This will lead you to differentiate multiple cases and perform runtime-casts.
You should better write an own class Player, which may be derived from Entity, and which brings along its own methods. Then, you can implement a class Enemy and a container of enemies, for example. And so on.
If you know the type of something at compile-time without losing any abstraction capabilities, you should choose this way. Manually decomposing different types at runtime is usually tedious and error-prone (in C# probably less than in C++, but still enough).
-
And how should I make relationship between elements? For example, I want a crate to be pushed when a player moves into it.
I could have the code in the Player class (on move, check if there's a crate in the designed position, if yes move both the crate and the player), but it isn't the best solution.
-
There is not the one and only solution. It strongly depends on your whole design.
For example, you might have a module that is in charge of physics (among others responsible for rendering, input, AI, general game logics, ...). An incarnation of the physics can be a class. This class provides functions to deal with several entities of the world, for example HandleCollision(), which takes two Entity objects by reference and reacts correspondingly. When your physics-related class grows and begins to take over many different tasks, you should split it (e.g. into entity movement, collision detection and response).
However, thats only one suggestion, as stated there are lots of possibilities. In my opinion, the most important point is to keep things modular and dependencies as small as possible.