SFML community forums
Help => General => Topic started by: Luponius on April 23, 2013, 07:39:03 pm
-
Hi there, I've spent the past few days just reading up on various kinds of things to attempt to expand my knowledge before I even bother trying anything interesting and I've always been asking the same question and hunting for a specific answer of it, so I figured I'd open a topic to discuss it.
My current goal, once I can wrap my head around game design concepts well enough is to make a small rpg, oldskool like with a set of stats and some variance in equipment and such. This of course means the enemies as well as friendly npcs would have the same amount of detail, possibly with the exception of the player due to swappable equipment and such.
Now the reason I made the thread is because I am curious as to how most coders out there would organize this, and what would you inherit from?
I'm still unfamiliar with SFML however I've attached a simple class structure which i kinda got off the top of my head. Obviously this would not be correct since I've never done this and therefore never had to sit down and tackle the problems specifically, but how would one organize this?
With that in mind I might be able to take a more focused direction in learning. My guess however, is the simpler the better, a single creature class which contains global stuff would probably be ideal, initiated once for the player, and then multiple more times with different details for the NPCs as well as enemies.
How would the sprites, animations and such be handled for these kind of situations? Btw I'm mainly seeking just discussion, although code examples would be nice and welcome.
[attachment deleted by admin]
-
Your class organization looks already good, there are just minor things (creature::Sprite inconsistenly named, player and ally class should not require a destructor).
But you are also right that you could as well leave things simple for now and just go with a single creature class. Not required attributes would then have an empty state. This has the advantage that you don't need to work through polymorphic pointers all the time.
For animations, you could have a look at how I solved it in my extension library Thor (doc (http://www.bromeon.ch/libraries/thor/v2.0/doc/group___animation.html), example (https://github.com/Bromeon/Thor/blob/master/examples/Animation.cpp)). You can directly use the Animation module, or write a simplified version if you don't need the flexibility. The class thor::FrameAnimation should contain the important parts in the latter case.
-
well, i wouldn't change much about it, although i'm too newbie to say if it's good or not :P
how did you created this layout? in which program?
i'm curious to see others opinions too...
-
how did you created this layout? in which program?
It's the Visual Studio class diagram. Just one of its many nice features :)
-
@Stauricus As nexus pointed out, in visual studio simply right click your project (Not the solution) and select View Class Diagram. In here you can see a representation of your relationships. This however doesn't allow you to create them in here, it's just a representation.
@Nexus. Regarding the constructors and destructors I wasn't even thinking, I cooked that up in a sketch-pseudo kind of way without thinking too much about the application factor. However one thing you mentioned which caught my attention was that creature::Sprite was inconsistently named. Care to explain please? =]
-
oh, got it. too bad i'm on Lubuntu + Code::Blocks... :o
-
creature::Sprite was inconsistently named. Care to explain please? =]
All the other member variables of creature are written in lowercase letters, so Sprite should be too.
By the way, why do you also inherit Sprite? Don't do that, the forum is full of reasons why not :)
-
Thanks for the reply, regarding the inheritance, I was just making a wild guess, once again it was something very rough and quick, however what would be best to inherit from, and would the class itself have capabilities of drawing itself to the renderwindow?
If so, how would that be done? Create a draw method which takes in a reference to the main drawWindow and use that argument to draw the this->Sprite on it or what?
-
If so, how would that be done? Create a draw method which takes in a reference to the main drawWindow and use that argument to draw the this->Sprite on it or what?
Yep.
-
In that case what should the creature class inherit from, then, if anything?
-
Either sf::Drawable or nothing.
-
When and why would we need to inherit from drawable?
-
I would not inherit anything but have a sprite (or whatever you need) as a member of your class and give it a draw function that takes an sf::RenderTarget& because I tend to think of my game objects relationship with their graphical representation as a "has a" relationship.
As a side note: as soon as you start to use inheritance for different types of game objects you should stop that and implement a component based game object system. In such a component system every object that is supposed to be rendered has a rendering component. See Tank's blog posts: http://stefan.boxbox.org/2012/11/14/game-development-design-1-the-component-system/ (http://stefan.boxbox.org/2012/11/14/game-development-design-1-the-component-system/). However, if your game is very simple your approach will make everything work with less headaches.
Have fun and keep us updated!